QRZ! Ham Radio 6

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 6 / QRZ Ham Radio Callsign Database - Volume 6.iso / pc / files / p_misc / netconf.arc / PACSAT.TXT < prev next >

Wrap

Text File | 1988-12-11 | 36.1 KB | 726 lines

The following is the text of a paper submitted for the 7th ARRL Networking Conference, October 1, 1988. It will appear in the conference proceedings which will be published by the ARRL. Please do not reprint this material without permission. ---------------------------------------------------- AMSAT's MICROSAT/PACSAT PROGRAM Tom Clark, W3IWI 6388 Guilford Rd. Clarksville, MD 21029 ABSTRACT In 1989 AMSAT-NA plans to launch the first of a series of low- earth orbit (LEO) sat-ellites dedicated to serving digital store- and-forward message handling. These satellites are quite small cubes, approximately 230 cm (9 inches) on a side weighing less than 10 kg; this small size has led to our calling the project MICROSAT. Despite the small size, the satellites are crammed with state-of-the-art electronics. This paper will review the development program leading to this design and some of the technical details as well as describing how the terrestrial user will make use of the resource. We are planning on the launch of 4 satellites using MICROSAT technology into LEO in early 1989, and several more launches over the next 2 years. A BIT OF HISTORY In October 1981, the ARRL, AMRAD and AMSAT jointly hosted the first Networking Conference when packet radio was in its earliest period of development. Doug Lockhart (VE7APU) and the VADCG group had put the first TNCs into our hands. Hank Magnuski (KA6M) and the PPRS had the first digipeater on the air. In the D.C. area a few of us (W4MIB, WB4JFI, K8MMO, W3IWI, KE3Z) were on the air making funny sounds. The seed was planted! On a warm sunny afternoon the following spring, at the AMSAT lab at NASA Goddard, I took Jan King (W3GEY) aside and told him of an idea I had. At the time we were building the AO-10 satellite which was to provide global scale communications from its vantage point in high earth orbit (HEO). My idea was to provide similar communications coverage from LEO using digital store-and-forward techniques, albeit not in real time. The basic idea was for the sender to uplink a message to the LEO satellite; then at a later time when it was in view of the recipient, it would be forwarded to him automatically. After some more design work, I enlisted the aid of Den Connors (KD2S) who was then spearheading the effort in Tucson which became known as TAPR. Den and I started beating the bushes for support for the program. When the ideas became known to AMSAT, some of the old timers accused us of having lost our minds with statements like "There aren't more than a couple of hundred people on packet. Packet radio will never amount to anything. etcetera etcetera". By the fall of 1982 we were starting to see some ground-swell of support, so Den and I scheduled a special meeting (to be held in conjunction with AMSAT's annual meeting) which was to get inputs from packeteers in several groups on the PACSAT concept. The second purpose was to try to see if we couldn't come up with a national protocol standard; the result was the adoption of AX.25 (for which some people STILL blame me!). Soon thereafter we found a potential sponsor who needed PACSAT support to aid in disseminating information on technologies appropriate to developing countries and thus was formed a tie between AMSAT and the Volunteers in Technical Assistance (VITA) and Gary Garriot (WA9FMQ). The VITA PACSAT project enlisted the assistance of Harold Price (NK6K), Larry Kayser (VE3QB/WA3ZIA, now VE3PAZ) and a number of others. The VITA/PACSAT team decided to test their messaging concepts on a UoSAT spacecraft resulting in UO-11's Digital Communications Experiment (DCE). The partnership between VITA and the UoSAT group has continued, and the UoSAT-D spacecraft (to be flown at the same time as our Microsats) is the culmination of that effort. In the meantime I told the Miki Nakayama (JR1SWB) and Harry Yoneda (JA1ANG) of JAMSAT of our design concepts. The JAMSAT/JARL team were able to implement many of these ideas in the mode "JD" hardware on the Japanese JAS-1 (JO-12) satellite. They also developed state-of-the-art reproducable 1200 BPS PSK demodulator designs which have become important for future spacecraft designs. Unfortunately the negative power budget on JO-12 has limited the utility of an otherwise excellent spacecraft. For the next couple of years any idea of our building a PACSAT in the USA languished. First we were busy building the AO-13 satellite in consort with AMSAT-DL. The American dependence on the Space Shuttle and the lack of suitable launches on which we could hitchhike made opportunities few and far between. We looked at low-thrust motors using water or Freon propellants to lift us to a suitable LEO if we used the Shuttle's GASCANs. Two groups flew small satellites ejected from GASCANs on the shuttle; one was NUSAT, built by a of students and faculty at Weber State College in Ogden, Utah. Then with the loss of the Challenger, even those hopes for our building a PACSAT were dashed. THE BIRTH OF MICROSAT The scene now shifts to November, 1987 in a hotel room in Detroit after the banquet at AMSAT's annual meeting. Jan King, Bob McGwier (N4HY), Phil Karn (KA9Q) and I are sitting around at 1AM. Jan starts telling us of a concept that he and Gordon Hardman (KE3D) have been thinking about. It involves a very small, simple satellite, a 9" cube. He describes how five 8" x 8" x 1.6" module "trays" would be stacked to make up the inner frame of a satellite. Then on the small 9" x 9" solar panels would make up the outside skin. He told us that he believed he had several different potential launches that could carry several of these cubes to LEO and asked us what we could do with the limited space. By 3 AM we had a conceptual design, we had done link margin calculations, we had selected a candidate CPU, and we had estimated size, weight and power requirements for each of the modules. The adrenalin flowing in our veins was at an all-time high! [ Figure 1. A photograph of the structural model of the MICROSAT satellite.] By early December we had refined the basic design. Dick Jansson (WD4FAB) had done a complete mechanical design. We held a preliminary design review at the AMSAT office and decided we were GO! While all this was going on, contacts were made with Junior DeCastro (PY2BJO) of the Brazilian BRAMSAT group, Arturo Carou (LU1AHC) of AMSAT-LU and with the NUSAT group at Weber State. Each agreed to join the team and we settled on building four satellites: The AMSAT-NA and AMSAT-LU satellites would be classical PACSATs. The Weber State satellite would be a PACSAT augmented by a TV camera which would send down pictures encoded in normal AX.25 packet frames. The Brazilian satellite would be the DOVE (Digital Orbiting Voice Experiment) which would "talk" voice bulletins which could be copied on a normal HT. PACSAT AND ALOHA First we need to review a little packet radio theory. Let us assume that the satellite operates with its transmitter and receiver on different bands so that the communications links are full-duplex. Let us also assume that there are many users, each with similar capabilities, who are spread out over the entire spacecraft "footprint". Let us further assume that traffic is balanced -- whatever goes up to the spacecraft equals what comes down, so the uplink and downlink channel capacity needs to be balanced. Since the ground-based users are spread out, the cannot hear each other. Each will transmit at random in the hopes that his packets make it thru. This is the classic ALOHA network configuration with "hidden terminals". It can be shown that collisions on the uplink channel will statistically reduce the channel capacity so that only (1/2e) = 18.4% of the packets make it thru. Thus, the downlink (on which there are no collisions) can support about 5 times as much traffic as can a single, collision-limited uplink. There are two ways out of this dilemma. First, the uplink users could use a data rate about 5 times the downlink; this approach was taken by the AMSAT-DL designers of AO-13's RUDAK experiment where a 2400 bit per second (BPS) uplink is balanced against a 400 BPS downlink. The second approach is to have multiple, separate uplink receivers. The FO-12 satellite has four 1200 BPS uplink channels balancing one 1200 BPS downlink. MODEMS AND RADIOS FOR PACSAT For our PACSATs, we have allowed for both solutions to the ALOHA limit. Like FO-12, there are to be four user uplink channels; however each of which can be commanded to support 1200, 2400, 4800 and possibly 9600 BPS uplinks. The downlink transmitter will start its life at 1200 BPS, but higher rates should be possible. Our design was heavily influenced by a decision we made early on: we would only use standards which were supported and available "off the shelf". Thus when our PACSAT comes to life, the ground user can use the identical hardware he uses for FO-12 today. The user's uplink will be at 1200 BPS, Manchester-encoded FSK and the downlink will be 1200 BPS binary PSK. These standards are supported by the TAPR and G3RUH modems, by the myriad FO-12 modems available on Akihabara in Japan, and by the DSP modems that N4HY and I have been working on. These "mo" modulator in these modems plugs into the mike jack on a stock 2M FM radio, which we assume can be tuned in 5 kHz steps. The satellite link margins should be such that 10-25 watts into an omnidirectional antenna should be adequate (providing everyone runs similar power). The "dem" demodulator plugs into an SSB-capable 70 cm receiver or all-mode transceiver, which needs to be tunable in 100 Hz (or preferably finer) steps. The PSK downlink should be "Q5" even with an omnidirectional antenna, providing the local noise level is low. The spacecraft's receiver has 15 kHz wide channels, regardless of the bit rate programmed at the spacecraft. The 1200 BPS data rate combined with an FM deviation of < 3 kHz, plus doppler shift, plus 5 kHz steps on a typical FM radio just fit the 15 kHz bandwidth. At some later date we will begin enabling selected uplink receiver channels for higher data rates (like 4800 BPS), but the user will now have to pre-steer the doppler and set his frequency more accurately than 5 kHz. Also most stock FM radios will not pass the 4800 BPS data rates without significant modifications. ONBOARD PACSAT Let us now discuss some of the features of the satellite's architecture. The electronics is divided into modules, with the space inside each module being about 7.8" x 6.5" x 1.5". The mechanical layout has five of these modules stacked atop each other as shown in Figure 2, which we will describe from top to bottom. | | | 2M uplink antenna | | _______!_______ | RECEIVER | |_______________| | TSFR | |_______________| | BATTERIES+BCR | |_______________| | CPU | |_______________| | TRANSMITTER | |_______________| / \ / \ / 70 cm downlink \ / antenna \ Figure 2. PACSAT LAYOUT RECEIVER The core of the receiver is the Motorola MC3362 single-chip FM receiver, couple with a stock NDK crystal filter with 15 kHz bandwidth centered at 10.7 MHz. The filter has very good skirts, with 80-90 dB ultimate rejection. The input to the 3362 is an IF in the 40-50 MHz range. The 1st LO in the 3362 is crystal controlled to mix to 10.7 MHz. Following the filter, the 3362's second mixer is driven from a crystal controlled 8.9 MHz 2nd LO to produce a final IF of 1.8 MHz selected for best linearity of the MC3362's FM detector (discriminator). The MC3362's FM detector drives two matched data filters, each of which uses one section of a TLC274 CMOS op amp; the 2-pole Butterworth filters are optimized for 1200 and 4800 BPS data rates. A CD4066 analog switch selects the output of one of the two filters to drive the data clipper section of the 3362. The appropriate filter is selected by the CPU. In addition, one section of the TLC274 produces an analog signal in the 0-2.5v range corresponding to the user's frequency (the "disc meter") and another produces a 0-2.5v analog signal corresponding to the user's signal strength (the "S meter"). All this circuitry takes up 1.5" x 3" on the receiver's circuit board and draws under 20 mW (< 4 ma at 5V). This circuit is replicated five times to provide the 4 user uplink channels plus a command/control channel. The design of this portion of the receiver was done by W3IWI with invaluable inputs from Eric Gustavson (N7CL). In front of this bank of five FM IF strips is a fairly conventional GaAsFET preamp with a noise figure < 1 dB. A narrow- band 3-stage helical filter provides selectivity between the GaAsFET preamp and a dual-gate MOSFET mixer which is driven by a crystal-controlled LO at about 100 MHz. The output of the MOSFET (at 40-50 MHz) drives five emitter followers to provide isolation between the five FM IF stages. The design of these stages was done by Jim Vogler (WA7CJO) and W3IWI. The total power consumption for the entire receiver is about 150 mW. [As a side note -- the receiver modules designed for PACSAT have been made easily reproducable, with very few "twiddles". All components, including the coils and helical filter are off-the- shelf items purchasable from sources like Digi-Key. It is anticipated that TAPR and/or AMSAT will make single-channel receiver kits available for use in dedicated packet link applications if there is enough interest]. TSFR For PACSAT, this is a dummy module. TSFR means "this space for rent", and is reserved for future expansion. POWER SYSTEM The Battery Charge Regulator (BCR) module contains the NiCd battery pack, the charger that conditions solar panel power to charge the batteries, and the switching regulators that produce the +5 and +10 v power needed by each module. The BCR and regulator design was done by Jon Bloom (KE3Z) with help from Gordon Hardman (KE3D). The solar panels make use of high-efficiency silicon cells with back-surface reflectors (BSR). BSR technology is new, but it allows for much higher efficiency; if a photon does not produce electricity as it passes thru the silicon on its way in, the reflector allows a second chance to "grab" it. The solar panel electrical and mechanical design was done by Jan King (W3GEY) and Dick Jansson (WD4FAB), and the solar panels are being produced under contract by Solarex. The price of space qualified NiCd batteries has become prohibitive, so new, low cost approaches have been adopted. Larry Kayser (VE3PAZ) and his group in Ottawa proved with UO-11 that if good, commercial grade batteries were purchased, they could be flight qualified. The qualification procedure involves extensive cycling to characterize the charge-discharge curve and temperature performance, X-raying the batteries to look for internal structural flaws, then selecting only the best cells, and then finally potting the batteries. While the solar panels produce about 14 watts, when averaged over a whole orbit (some time is spent in eclipse), and after losses in power conditioning about 7-10 watts is available. CPU In many ways the flight computer is the key to PACSAT. At the time we were selecting the CPU, the SANDPAC group in San Diego were finishing the first pre-production run of the new PS186 network switch. Based on their experience, we selected a similar architecture. The flight CPU is based on the NEC CMOS V-40 CPU (quite similar to an 80C188). The flight CPU includes EDAC (Error Detection and Correction) memory for storage of critical software, plus bank-switched memory for data storage (i.e. "RAM Disk"). We hope to fly upwards of 10 Mbytes on each PACSAT (limited only by available space and the price of memory chips). The CPU, when running hard draws about 2 watts of power. A companion paper by Lyle Johnson (WA7GXD) and Chuck Green (N0ADI) describes the CPU's architecture in much more detail. A paper by Bob McGwier (N4HY) and Harold Price (NK6K) describes the multi-tasking software. Jim DeArras (WA4ONG) is converting Lyle and Chuck's wire-wrapped prototype to multi-layer circuit board. The ROM-based bootloader to allow recovery from disasters has been written by Hugh Pett (VE3FLL) whose code had previously saved the day on UoSAT. TRANSMITTER At the time of this writing, the transmitter is still in the design phase, so some of these parameters may change. The transmitter will be BPSK modulated, and will have its power output changeable by ground command. The current plans are for two power levels, about 1.5 or 4 watts. The transmitter starts out with a crystal oscillator at 109 MHz, and is followed by two doublers to 436 MHz. This design is being done by Stan Sjol (W0KD). Gordon Hardman (KE3Z) is working on a power amplifier using a Motorola MRF750 driver and a MRF752 output stage. The collector voltage on the driver stage will be command selected to be either the +5 or +10v bus to provide power agility. This collector voltage may be amplitude modulated to provide some time-domain shaping to minimize the transmitted bandwidth. Transmitter development is also being done in Canada by Bob Pepper (VE2AO). GLUE The myriad mechanical details were all sorted out before we cut a single piece of metal by Dick Janssen (WD4FAB); Dick made extensive use of modern CAD techniques and all drawings were done with AutoCAD (see Figure 3). In Boulder, Jeff Zerr has been shepherding the detailed mechanical layout and find what pieces don't fit. A "show and tell" model was built by ???? with help from Dick Daniels, and a mechanical mockup for vibration testing has been built by Jeff Zerr. When we began developing the Microsat concept, we took a look at problems that had been major hassles on earlier satellites. High on the list were problems in building a wiring harness and testing individual modules. We also wanted a design that allowed a "cookie cutter" approach to manufacturing since we anticipate a number of launches in the next few years. We came to the conclusion that we needed to develop a bus-like wiring approach with all modules having similar interfaces, and we needed to minimize the number of wires. I took on the task of solving this problem and defining the electrical "glue" that holds the system together. After exploring a number of options, the design we adopted was to use hi-rel DB25 25-pin connectors on each module and use a 25- wire bus made like a flexible printed circuit. Of the 25 wires, about 40% are used for power distribution, about 40% to carry packet data from the receiver to the CPU and from the CPU to the transmitter, and the final 5 wires are used to let the CPU control functions in the individual modules and for analog telemetry. [ Figure 3. Part of one of WD4FAB's drawings showing MICROSAT assembly details. ] AART In order to squeeze all these command, control and telemetry functions into only five wires, we have built a very small (7 inches long!) LAN with the CPU acting as the network master node and each module being a slave node. Data communications from CPU to module consist of two byte packets; the first byte (with the MSB=1) addresses up to 128 slaves, and the second byte (with MSB=0) is a 7-bit received data field to be passed to the module (RXD). On receipt of a valid address, the module automatically sends back two 8-bit bytes (TXD) of data on another wire. All data is sent with normal asynchronous protocols. On the CPU side, this async data is generated and received by the UART built into the V40 chip. The protocol is easily simulated on a PC, so testing each module does not require a complete working spacecraft. In each module, we use a clever IC: the Motorola MC14469F Addressable Asynchronous Receiver/Transmitter (AART). The 14469 is a 44-pin surface mount part (also available as a 40-pin conventional DIP) which implements the protocol just described with very few external parts. It has separate pins for the 7 address bits, the 7 RXD bits and the 16 TXD bits. The 7 RXD bits are used for a number of functions. The MSB of this word is used to select analog vs. digital functions, with the control data specified by the remaining 6 bits. For digital functions, the 6 bits are treated as two 3-bit nibbles which constitute the address and data for three CD4099 addressable latches, resulting in 24 bits of digital data being available for control functions in the module. When the MSB selects analog functions, the 6 bits are taken as addresses for CD4052 CMOS analog multiplexer chips which decode 6 discrete analog telemetry samples plus four thermistors. When a module is selected in analog mode, the selected analog signal is switched onto two wires (signal plus return) in the 25-wire bus, and when the module is de-selected the two wires are floated. A single, fast 8-bit 0-2.5v A/D converter in the CPU handles all spacecraft analog telemetry. Each module is responsible for pre- conditioning its analog signals to fit the 0-2.5v range. All these parts, including some op amps to condition the thermistor signals, plus the DB25 spacecraft bus interface connector and tie-points for all signals needed in the modules are fitted onto a 7.8" x 1.5" board which is mounted against one wall of the module frame. The interface boards in each of the "slave" modules are identical except that the AART chip is strapped to different addresses. This small board has been dubbed the AART board. It was designed by W3IWI and Bob Stricklin (N5BRG). Each board requires 5 mW of power (about 1 ma at 5v). THE OTHER MICROSATS DOVE So far we have described the two Microsat PACSATs: those sponsored by AMSAT-NA and AMSAT-LU. The BRAMSAT DOVE spacecraft is still in the final design phases, but it will be built from many of the same pieces and will have the same general mechanical layout. DOVE will transmit its digitized voice signals in the 2M band with conventional FM modulation. Rather than designing a different receiver system, we have decided to have the command uplinks also on 2M; the DOVE transmitter will turn itself off every few minutes to listen for commands. Only the transmitter module is different for DOVE. As of the time of this writing we are planning to use differentially-encoded voice synthesis (e.g. "delta modulation") with up to 4-bit encoding of the differential data. Preliminary design on the speech synthesizer has been done by Bob McGwier (N4Y) and W3IWI and is being simulated using our DSP hardware. NUSAT The Weber State NUSAT MICROSAT is different mechanically from the PACSATs, shown in Figure 4. | | | 2M uplink antenna | | _______!_______ | TV CAMERA | |_______________| | CPU | |_______________| | BATTERIES+BCR | |_______________| | RECEIVER | |_______________| | TRANSMITTER | |_______________| / \ / \ / 70 cm downlink \ / antenna \ Figure 4. NUSAT LAYOUT The major difference is that NUSAT has a CCD TV camera in the top module. The TV camera is connected to a high-speed multi- channel "flash" A/D converter which can digitize incoming video signals at 10 MHz sample rate. Its data is stored in memory which can also be accessed by the CPU. The Weber TV camera module and CPU were placed in adjacent modules so that the memory could be easily dual-ported. The sample rate for the A/D converter and the input signal source can be selected by the CPU. The primary signal source is a CCD TV camera equipped with an electromechanical iris built into its lens. The iris's aperture can also be controlled by the CPU. The camera's field of view allows a 350 km square to be imaged from the satellite's 800 km high orbit. The camera assembly occupies about 1/4 of the space in the module. It is planned to use video data compression techniques to minimize the downlink data requirements; Weber State and AMSAT-NA plan to have software to support these advanced video techniques available around launch time. Weber State also plans to try a 1269 MHz video uplink. Video data from this uplink will be digitized by the "flash" A/D converter and loaded into the dual ported memory, just like data from the CCD camera. It is also hoped that the TV camera can be used as an visible and IR spectrometer covering the 400 to 2000 micrometer wavelength band. The other NUSAT modules are nearly identical to the PACSATs and NUSAT could be also turned into a PACSAT merely by loading different software. The Weber State team consists of a number of students, staff and faculty members from the Center for Aerospace Technology (CAST) including Bob Twiggs, Bob Summers and Chris Williams. THE FIRST MICROSAT LAUNCH AMSAT-NA and the UoSAT group have worked with the European Space Agency and Ariannespace to develop a new launch capability for very small satellites. This will be first tested on the launch of the SPOT-2 Earth Resources Satellite in early 1989. On that flight there will be SIX small satellites -- our four Microsats and two somewhat larger UoSAT spacecraft. The orbit is nearly ideal -- sun synchronous at 800 km altitude, much like the Oscar-8 orbit. At mid-latitudes, passes will occur twice per day at predictable times around 10:30 A.M. and 10:30 P.M. local time. USING THE MICROSAT SATELLITES As we mentioned before, our PACSATs and Weber State's NUSAT use ordinary AX.25 packet protocols. To receive any of the three, you merely need to add a PSK demodulator to your 70 cm receiver. The uplink requirements are modest and the same as FO-12. At a later time, when transmitter technology permits and user loading dictates, some of the receiver channels will be reprogrammed to higher speeds. But initially, if you are able to use the FO-12 satellite, then you are all set. The spacecraft software that you will see will be designed for message handling, and the code is being written by Bob McGwier (N4HY) with inputs from a number of us. The initial software will probably look very much like a W0RLI/WA7MBL BBS system, with a few enhancements. First of all, the prompt that the satellite will send to you will have two telemetry numbers in it -- these are your signal strength and discriminator meter readings. The discriminator meter should be invaluable in helping you center your signal in the receiver's passband and its use will become mandatory as we migrate to higher uplink speeds. The spacecraft software will support multiple, simultaneous users. There may be commands that allow you to request specific telemetry information from the satellite. I anticipate that much of the utility of these satellites will be as an augmentation of the terrestrial HF long-haul message forwarding networks. If this proves to be true, then fully automated gateway stations will make heavy use of the satellite capabilities. Therefore it is important that we design both the ground-based and flight software to work together smoothly. We have had ongoing discussions with the writers of BBS code (like W0RLI and WA7MBL) to make sure that both sides of the link will be ready on launch day. In these discussions we have been devising schemes so that the burden of maintaining routing information resides on the ground. New forwarding protocols in which the receiving station tells the sender what message addresses it can handle are being defined. It is likely that these will be coupled with heirarchial domain-oriented addressing schemes like are used by TCP/IP protocols. A user on the W3IWI BBS would have an address like W3XYZ@W3IWI.MD.USA and if I were operating as a gateway for the MD/VA/DE/PA/NJ area, I would be able to inform the spacecraft to send me any messages so addressed. At the same time that "connected" mode activity is going on, the satellite will be sending UI "broadcast" (i.e. UNPROTO) frames with telemetry and bulletins of interest to all. On NUSAT, digitally encoded pictures of the earth will be sent as UI frames which will be reassembled by the user on the ground. THE FUTURE We have reason to believe that there are a number of launch opportunities to LEO for very small satellites. We have designed our Microsats to be easily reproducable. As new capabilities (perhaps 9600 or 19,200 BPS modems? Experiments to fit into the TSFR module? ) are developed, we feel there will be opportunities to fly them. We anticipate non-amateur uses of our technology. Initial discussions with scientists specializing in oceanography and seismology have shown that they have a need for low-cost data collection systems from remote locations. We anticipate a scheme for a commercial licensee to "sell" our technology in these markets. Just like royalties from TAPR's TNC2 project have provided resources for future development activities in packet radio, we hope that Microsat royalties will provide a similar legacy for advancing amateur satellite technology. We also see that the Microsat technology provides a perfect way for fledgling space groups associated with other AMSAT organizations around the world and with universities to develop their own satellite programs. Don't be surprised to see Microsats being built by people from many nations. The spacecraft operating software can be uploaded from the ground. As NK6K and N4HY discuss in their companion paper, the software we will be flying is the most complex ever attempted in the amateur satellite program. It probably will crash! We have designed in several safeguards to make this possible. With this flexibility, we also have the ability to try new things. Perhaps we will see new mail-handling protocols developed which use datagrams. Perhaps we will see a PACSAT programmed to be a TCP/IP FTP file server. As the old adage states: IT'S ONLY SOFTWARE ! -------------------- PARTING COMMENTS AND ACKNOWLEDGMENTS The most important "glue" that holds a project like this together is the project manager. We are indeed fortunate to have Jan King (W3GEY), with his wealth of experience, his contacts in the aerospace industry, his mother-hen persistence in reminding us of the rigors of space, and his compulsive personality to make sure everything happens. Jan's "glue" binds together a team of high-strung, emotional prima donnas who are equally compulsive. Many of the team members have invested a lot of 3AM mornings working on this project! All the team members have had to wear very thick skins to withstand the FLAME ON! communications blasts some of us are prone to emit. Bob Mcgwier, Dick Jansson and Lyle Johnson all deserve special credit for service above and beyond the call of duty. This project has significant players spread out all over North America, with major activities in NJ, MD, VA, FL, CO, UT, AZ, TX and CA. Unfortunately amateur radio communications are inadequate to keep such a dispersed team working together. We have relied heavily on commercial electronic communication channels, particularly AMSAT's network on GTE TeleMail and TAPR's channels on CompuServe, plus a lot of phone calls. Every few months we get a number of the people in one place and lock the door to make sure everyone REALLY understands what is happening. We have made heavy use of various CAD tools during the development activities. Mechanical layout was done with AutoCAD. ORCAD was heavily used for developing schematics, wiring lists, parts lists and net lists. CAD PCB layout used Smartwork, ORCAD PCB and Tango. See Figure 5 for an axample of some of this use of CAD techniques. [ Figure 5. One of W3IWI's ORCAD schematics of the MICROSAT receiver IF strip.] We have done some experimentation using higher-level networking for technical communications to move CAD data using my TOMCAT FTP file server which has a SLIP port in addition to being on the "real" network. There are two organizations not mentioned earlier that have contributed a lot to this project: TAPR and the ARRL. For many of the volunteers working on this project, the distinction between TAPR and AMSAT is fuzzy since they seem to wear two hats. In addition to the TAPRites working on this project, TAPR has made vital contributions of funds and hardware, without which we couldn't make it. Special thanks to Andy Freeborn (N0CCZ) for helping to make the TAPR/AMSAT interface smooth. At the ARRL labs in Newington, Paul Rinaldo and Jon Bloom have made many vital contributions. From the AMSAT organization, two people deserve a lot of credit. Vern Riportella (WA2LQQ) was instrumental in arranging the AMSAT-LU and BRAMSAT participation in the project. Martha Saragovitz has acted as mother confessor, paid bills, handled meeting logistics and kept smiling thru it all, despite repeatedly crying out "Where's the money coming from?".